Domain Name System
The Domain Name System (DNS) is a distributed database of information about devices (also called hosts) connected to the Internet. Specifically, DNS contains information to map between human readable names (used as a mnemonic device) and IP addresses (used in Internet routing):                Example 1: Web site name “www.google.com” maps to IP address “74.125.224.72”        Example 2: Email address “john.smith@bestcompany.com” maps to IP address “208.49.79.242”        
This information is stored in DNS database entries which are referred to as DNS Resource Records (RRs). DNS servers respond to client queries by giving information about Internet connected devices (hosts) stored in the DNS records. The most common query is translating a name to an IP address. This function is termed DNS name resolution. Technically, the name that is resolved is referred to as an FQDN. There are also other types of possible DNS queries which will be discussed herein.
A semi-manual scheme for DNS worked initially, but did not scale well when the number of hosts connected to the Internet started growing exponentially. An investigation was then made to determine a more automatic and scalable solution which resulted in a key series of IETF standards defining DNS. See RFC 1034 and RFC 1035, which are incorporated by reference in their entirety.
DNS today is a distributed database spread over many computer servers located worldwide. The database is organized around the concept of domain names (e.g., “.com” is part of a domain name, and “www.bestcompany.com” is a FQDN). Each domain name is essentially a path in a large inverted tree, called the domain namespace (see FIG. 1). A domain is a sub-tree of the entire space. The tree structure has a single (logical) root at the top. The depth of the tree is limited to 127 levels. Each node in the tree has a text label name that can be up to 63 characters long. Domain names are always read from the leaf node toward the root with dots separating the names in the path. So, for example for the FQDN “www.bestcompany.com”, the “.com” would be at the top of the tree and is referred to as the Top Level Domain (TLD). Then “.bestcompany” would be next down the tree, and “www” would be at the bottom leaf of the tree.
As mentioned previously, DNS database entries are stored in a format called RRs. The RRs are organized by domains or specific domain names (FQDNs). FQDNS are ultimately associated with a physical network device, while domains (e.g., “.com”) are used to identify a group of devices. There are various types of RRs classified by the type of information related to the device that they contain. Some exemplary DNS RRs are listed in Table 1.
TABLE 1Types of DNS Resource Records (RRs)Type of RRNameDescriptionAAddress RecordThe IPv4 address of the host(device) for the given FQDNAAAAIPv6 Address RecordThe IPv6 address of the host(device) for the given FQDNMXMail Exchange RecordThe E-Mail Exchange serverfor a given domainNSName Server RecordThe authoritative DNS nameserver for the given domainPTRPointer RecordA pointer to another part ofthe DNS name space(Often used to map an IPaddress to a host name)SRVService Locator RecordA generalized service locationrecord that gives the FQDNand port number of serversfor the specified service(This is used for newerprotocols instead of creatingprotocol-specific records suchas MX (used for E-Mail)).TXTText RecordText string that can beinterpreted as required bydifferent protocols
DNS queries and responses are typically sent directly over UDP packets on port 53. A TCP transport option also exists but is not the recommended option for DNS queries/responses which are typically fairly short transactions. DNS defines a single message format with three components as shown in FIG. 2.
The three components are header portion 105, question portion 107, and answer portion 109. With regard to header portion 105, there is fixed twelve byte header with fields that describe the type of message and the size of the variable portions. Question portion 107 contains one or more queries for information being sent to a DNS name server. Answer Portion 109 contains one or more RRs in three sub-components as an answer to the query/question in question portion 107, such as answer 111, authority 112, and additional 113. Answer 111 is a RR(s) that answers the question directly. Authority 112 is a RR(s) that points to authoritative DNS name servers that can be used to continue the resolution process. Additional 113 is a RR(s) that contains additional information related to the query that is not strictly necessary to answer the original question.
FIG. 3 illustrates a typical message sequence diagram for a DNS lookup initiated by a user doing web browsing. At step 121, a user at laptop 130 wants to read the latest Google business news. This information is entered through a user interface associated with browser 131 of laptop 130. Browser 131 then recognizes that it needs to get the IP address of “google.com.” So browser 131 contacts DNS client 132 in laptop 130 with this request. At step 122, once DNS Client 131 gets the request, it forms a DNS Message query with FQDN=“google.com”. This query is sent to default DNS server 133 over Internet 120. The IP address of DNS server 133 may be already available in DNS client 132. The IP address of DNS server 133 may have been pre-provisioned in the laptop or retrieved at the laptop boot up process by a protocol such as DHCP.
At step 123, DNS server 133 does an internal lookup on the received query of step 122 and determines that the server of the “.com” domain is DNS server 134. So a DNS message (containing the RR) is sent back to DNS client 132 to inform it that it should do a recursive search and contact DNS server 134 with the same query. At step 124, DNS client sends DNS message with similar information of step 122 to DNS server 134. In this example, DNS server 134 is the authoritative domain server and so no further recursion is necessary. At step 125, DNS server 125 will sends a DNS message with a response to step 124 containing the “A” RR which contains the IP address (74.125.224.72) of the requested “google.com” server. At step 126, DNS client 132 sends the “google.com” IP address from the DNS Message to the browser 131. At step 127, browser 131 sends an HTTP Get request directly to the “google.com” IP address (74.125.224.72) to retrieve the content that it wants, which may be the latest business news. At step 128, the “google.com” server responds with an HTTP response with the appropriate latest business news content.
DNS-SD
DNS-Service Discovery (DNS-SD) is a relatively new feature that has been added to DNS in recent years. DNS-SD refers to the use of DNS to discover available local network IP based services in addition to the usual name resolution function. For example, querying DNS-SD for available printers in the local network that can be accessed via IP. Specifically, given a type of service (e.g., printing) that a client is looking for this mechanism allows clients to discover a local list of devices (named instances) of that desired service, in a given domain, using standard DNS-queries. The commercial pre-cursor to the IETF standardized solution was by Apple Computer and was referred to as “AppleTalk” (sometimes also referred to as “Bonjour”). See RFC 676, which is incorporated by reference in its entirety.
In IETF, an IP “service” is recognized by a combination of three pieces of information that includes a service name (e.g., FTP, HTTP), a transport protocol (e.g., UDP, TCP), and a port number of the transport protocol. An extensive registry of known Internet IP services is maintained by IETF in a service name and transport protocol port number registry. See http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml, which is incorporated by reference in its entirety.
Technically, DNS-SD is composed of two functions. The first function is referred to as multicast DNS (mDNS). mDNS provides the ability to perform local network DNS operations in the absence of any conventional unicast DNS server by utilizing local IP multicast functionality. Thus, devices can directly answer local IP multicast DNS queries themselves instead of requiring dedicated DNS servers to respond to the query (e.g., a printer will directly answer multicast DNS queries looking for printing services). mDNS also allows devices to pro-actively advertise their supported/changed services using link-local multicast. In addition, mDNS designates a portion of the DNS namespace to be free for local use (e.g., a new “.local” domain), without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. See RFC 6762, which is incorporated by reference in its entirety.
The second function is itself (a bit confusingly) called DNS-SD. It is described in RFC 6763 (which is incorporated by reference in its entirety) and specifies the changes required within the DNS record structure to support service discovery queries (e.g., configuring DNS to support more than the classical name resolution queries). It can also be used in a pure unicast mode for querying for specific services of a given domain. However, this unicast mode is not used as general service discovery function today.
The combination of DNS-SD and mDNS is typically referred to as just “DNS-SD” when used in the context of dynamic multicast service discovery in a network. The discovery of services is done as needed directly by clients sending multicast queries and receiving (unicast) responses directly from the devices that support the requested IP based services. This service discovery works for local networks (e.g., cannot discover services dynamically across multiple LANs).
FIG. 4 illustrates a typical DNS-SD message flow. At step 141, a user wants to print a color document from word processor 136. Word processor 136 recognizes that it needs to get the IP address of a color printer (e.g., color printer 139). So word processor 136 sends a message to DNS client 132 in laptop 130 with this request. At step 142, once DNS client 132 gets the request it determines that it should form a DNS-SD (multicast) message query indicating that it is looking for a “Color Printer”. This query is sent by IP multicast over LAN 140 that laptop 130 is connected with. The IP multicast mechanism will automatically distribute the DNS-SD query to all devices connected to LAN 140 (the message should not go beyond LAN 140). Unlike standard DNS queries (which are sent over UDP port 53), a multicast DNS-SD query is sent over UDP port 5353. Also, a multicast DNS-SD domain is specified as having an FQDN that ends with “.local” suffix, such as “ColorPrinter.local”.
At step 143, multiple devices in LAN 140 receive the DNS-SD multicast query, but, here, only color printer 139 has a matching service type. Color printer 139 sends a DNS-SD message (unicast) response including the IP address (e.g., 192.168.0.11) of the requested service server. At step 144, DNS client 132 of laptop 130 sends the IP address of color printer 139 to word processor 136. At step 145, word processor 136 sends an HTTP Post request directly to the IP address of color printer 139 to request that the attachment is printed. At step 146, color printer 139 responds with a successful HTTP response code (201) to indicate that the attachment was successfully printed.
As mentioned previously DNS-SD is primarily used to discover IP based services in the local network. DNS-SD uses a combination of three standard DNS RRs to identify services which usually includes Pointer Record (PTR), Service Locator Record (SRV), and Text Record (TXT). DNS-SD searches involve a client sending a DNS query that specifies in the search parameters to look for a particular service type in the PTR records for a given domain. The DNS-SD servers then return a set of zero or more SRV/TXT pairs that gives the target device (host) name and port where the service instance can be reached (in the SRV RR) as well as ancillary information (in the TXT RR). The IP address of the target device can then be obtained from the associated “A” or “AAAA” record.
Hybrid DNS-SD Proxy
A recent draft hybrid unicast/multicast DNS-based service discovery proposes utilizing a hybrid proxy to allow selective wide area discovery of IP based services. See http://tools.ietf.org/html/draft-ietf-dnssd-hybrid-00, which is incorporated by reference in its entirety. Specifically, the draft proposes a proxy that will use mDNS to discover DNS-SD services in the local network, aggregate the responses, and answer back to a requesting client in a different LAN. This will also require key changes to the naming system in DNS (which is fairly controversial and has not yet been agreed to in IETF). Currently, the DNS domain names are ultimately associated with a given device as described previously. If the hybrid unicast/multicast DNS-based service draft is approved then it will allow a LAN (e.g., local link), instead of individual devices, to be also named (e.g., “4thFloor.Building1.companyX.com”) so that it can be queried to search for a given service.
FIG. 5 illustrates an exemplary flow for a hybrid DNS-SD Proxy scenario. At step 151, a query is required to be sent to a specific “named” LAN (e.g., 3rd floor of BestCompany) to search for a color printer. At steps 152-154, the normal (unicast) DNS query mechanism will result in the query being forwarded to the DNS-SD proxy 150 for the given LAN 140 (e.g., 3rd floor of BestCompany). At steps 155-156, DNS-SD proxy 150 triggers an mDNS request. The devices in LAN 140 receive the DNS-SD multicast query, but only color printer 139, which has a matching service type (of Color Printer), will answer. Color printer 139 sends a DNS-SD message (unicast) response including the IP address of the requested service server. At steps 157-158, the DNS response with the IP address is relayed back to word processor 136. At step 159, word processor 136 then sends an HTTP Post request directly to the IP address of color printer 139 to request that the attachment is printed.
DNS-SD can currently discover and advertise IP based services (e.g., printer, fax, etc.) in the local network, but there is a need for a system that works across LANs.